Skip to content

Conditional addition of System.Runtime.InteropServices.RuntimeInforma… #267

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

AlexandreEXFO
Copy link
Contributor

Description

The NuGet package 'System.Runtime.InteropServices.RuntimeInformation' (version 4.3.0) is indeed quite old and hasn't been updated in a long time. However, this is by design - you typically don’t need to reference it manually anymore if you're targeting modern .NET versions.

  1. Modern .NET (Core, 5, 6, 7, 8+)

If you're using .NET Core or .NET 5+, 6+, etc., the RuntimeInformation class is built into the runtime via the 'System.Runtime.InteropServices' namespace. You do not need to install the NuGet package separately.

  1. .NET Framework 4.7.1 and Above

Starting with .NET Framework 4.7.1, RuntimeInformation is also included in the framework itself, so again, no need to install the NuGet package

  1. If You're on Older Frameworks

If you're targeting older like .NET Framework 4.5-4.7 or .NET Standard 1.1, then the NuGet package is still valid and necessary. But for anything newer, it's redundant.

N.B.: The 'System.Runtime.InteropServices.RuntimeInformation' library (version 4.3.0) appears to be the one used when explicitly specified for newer versions of .NET. A vulnerability is reported in System.Private.Uri (version 4.3.0) which is a transitive dependency of the 'System.Runtime.InteropServices.RuntimeInformation' library (version 4.3.0).

Type of change

  • Refactor (non-breaking change which improves code quality or performance)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How has this been tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Test configuration:

  • OS version: Windows 11 + Ubuntu 24.04
  • Firmware version: 5.7.1
  • Yubikey model1: YubiKey 5 NFC

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have run dotnet format to format my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Footnotes

  1. See Yubikey models (Multi-protocol, Security Key, FIPS, Bio, YubiHSM, YubiHSM FIPS)

@DennisDyallo
Copy link
Collaborator

DennisDyallo commented Jul 1, 2025

Hi and thanks for your interest into the SDK!

I appreciate this PR. However, I'm thinking the best route is probably to just bump the target framework from net47 to net472, or perhaps all the way to net481.

Updating addresses performance, greater API and Netstandard 2.0 support, as well as upgrades addresses vulnerabilities (CVE-2019-0981: Denial of Service in System.Private.Uri)

These are in place upgrades that most machines should have by now.

NET 472 is included on Windows Server 2019 (WS2019 is EOL by Msft) and most users will have it installed already.
NET 48 is included in Server 2022, and is supported by and Windows Server 2008 R2 and upwards. Most users should have it already.

Based on researching the compatibility of different .NET targetFramework versions and Windows and Windows server, I recommend upgrading to net48 to enable the performance improvements, vulnerability patches and API features. This version allows us to upgrade and ensures the broadest compatibility.

image

Below are the changes for each of these version updates:


.NET Framework 4.7

  • BCL: C# 7.0 ValueTuple support, ECC cryptography improvements, SerialPort memory leak fix.
  • CLR: JIT and GC performance improvements, EventSource buffer overflow fix.

Full changelog


.NET Framework 4.7.1

  • BCL: Full netstandard2.0 support, ResourceManager race condition fix, improved Parallel.For reliability.
  • Security: SHA-2 support for Forms Authentication.
  • General: Numerous bug fixes and performance improvements.

Full changelog


.NET Framework 4.7.2

  • ASP.NET: Various bug fixes and performance improvements.
  • BCL: Cryptography, collections, and serialization improvements.
  • General: Included with Windows Server 2019.

Full changelog


.NET Framework 4.8

BCL & CLR:

  • zlib updated to 1.2.11.
  • DateTime/DateTimeOffset leap second handling.
  • Reduced memory allocations in cryptography.
  • New API for certificate thumbprints.
  • Improved GC, JIT, and threading performance.
  • AppDomain and process shutdown reliability improvements.

Full changelog


.NET Framework 4.8.1

Native Arm64 support: .NET Framework now runs natively on Arm64, improving performance over x64 emulation.

Full changelog


@DennisDyallo DennisDyallo added the dependencies Pull requests that update a dependency file label Jul 1, 2025
@AlexandreEXFO
Copy link
Contributor Author

@DennisDyallo : I'm quite comfortable with the proposed change. I'll make the changes. I just didn't dare make the change to stay compatible with the supported .NET versions since officially according to Microsoft's documentation .NET Framework 7 is still supported (https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework).

@AlexandreEXFO
Copy link
Contributor Author

I just saw that another PR has been opened: #271.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Development

Successfully merging this pull request may close these issues.

2 participants